COMMENT ⊗   VALID 00036 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00006 00002	BUG-LISP and LISP-FORUM
C00011 00003	∂03-Apr-81  0610	JerryB at MIT-AI (Gerald R. Barber) 	Improving the LISP working environment by taking a lesson from...   
C00029 00004	∂18-Jun-81  2147	Richard M. Stallman <RMS at MIT-AI> 	nested function definitions interfering with extensibility.    
C00047 00005	∂28-Sep-81  0617	Mark L. Miller <MILLER at MIT-AI> 	Suggested new lambda-list syntax   
C00048 00006	∂11-Jan-82  0932	George J. Carrette <GJC at MIT-MC> 	backquote trivia, for you history fans.
C00050 00007	∂11-Jan-82  0939	HES@MIT-AI
C00057 00008	∂11-Jan-82  1551	Don Morrison <Morrison at UTAH-20> 	clarification regarding backquote query
C00060 00009	∂12-Jan-82  1446	Jon L White <JONL at MIT-MC> 	'backquote' actions 
C00072 00010	∂16-Jan-82  1132	William G. Dubuque <WGD at MIT-MC> 
C00091 00011	∂25-Jan-82  2316	FININ at WHARTON-10 (Tim Finin) 	Interlisp and MacLisp (almost)  
C00108 00012	∂30-Jan-82  0728	kwh@MIT-AI 	minilisp
C00112 00013	∂30-Jan-82  1405	Jon L White <JONL at MIT-MC> 	Comparison of "lambda-macros" and my "Two little suggestions ..."
C00120 00014	∂30-Jan-82  1446	Jon L White <JONL at MIT-MC> 	The format ((MACRO . f) ...)  
C00122 00015	∂01-Feb-82  0752	Jon L White <JONL at MIT-MC> 	Incredible co-incidence about the format ((MACRO . f) ...)  
C00124 00016	∂01-Feb-82  0847	HIC at SCRC-TENEX 	Incredible co-incidence about the format ((MACRO . f) ...)   
C00128 00017	∂17-Feb-82  2001	Jon L White <JONL at MIT-MC> 	SHARPM    
C00141 00018	∂22-Feb-82  0121	Rod Brooks <ROD at SU-AI> 	DO loses.    
C00143 00019	∂22-Feb-82  1241	2Lt Eric J. Swenson <EJS at MIT-MC> 	Interlisp and MacLisp (almost)   
C00145 00020	∂22-Feb-82  1337	Glenn S. Burke <GSB at MIT-ML> 	DO loses.    
C00149 00021	∂23-Feb-82  2026	George J. Carrette <GJC at MIT-MC> 	Closing Files.
C00150 00022	∂26-Feb-82  1319	FEINBERG at CMU-20C 	DSK:
C00151 00023	∂27-Feb-82  1153	EB@MIT-ML 
C00152 00024	∂27-Feb-82  1153	Jon L White <JONL at MIT-MC>  
C00154 00025	∂27-Feb-82  1247	Jon L White <JONL at MIT-MC> 	Compilation bug seen in DO loop    
C00173 00026	∂06-Mar-82  1904	Alan Bawden <ALAN at MIT-ML> 	how am I supposed to deal with this behavior?
C00175 00027	∂08-Mar-82  0755	Jon L White <JONL at MIT-MC> 	Wrong result   
C00180 00028	∂08-Mar-82  1629	FEINBERG at CMU-20C 	Restricted JFNs    
C00189 00029	∂16-Mar-82  1643	George J. Carrette <GJC at MIT-MC> 
C00190 00030	∂23-Mar-82  1309	John G. Aspinall <JGA at MIT-MC> 	fixing, flooring, ceiling,...  
C00192 00031	∂11-Apr-82  1340	Glenn S. Burke <GSB at MIT-ML> 	assq compatibility with Maclisp  
C00211 00032	∂20-Apr-82  1831	Alan Bawden <ALAN at MIT-MC> 	&mumbles at all levels.  
C00217 00033	∂21-Apr-82  2203	JonL at PARC-MAXC 	Re: &mumbles at all levels -- BIND-ARGS  
C00219 00034	∂22-Apr-82  1136	George J. Carrette <GJC at MIT-MC> 	&mumbles at all levels. 
C00221 00035	∂22-Apr-82  1324	Stavros M. Macrakis <MACRAK at MIT-MC>  
C00222 00036	∂22-Apr-82  1614	Stavros M. Macrakis <MACRAK at MIT-MC>  
C00228 ENDMK
C⊗;
BUG-LISP and LISP-FORUM
∂03-Apr-81  0610	JerryB at MIT-AI (Gerald R. Barber) 	Improving the LISP working environment by taking a lesson from...   
Date:  3 APR 1981 0908-EST
From: JerryB at MIT-AI (Gerald R. Barber)
Subject: Improving the LISP working environment by taking a lesson from...
To: SHRAGE at WHARTON-10, Deutsch at PARC-MAXC
CC: LISP-FORUM at MIT-AI, nil at MIT-MC

    Date: 10 Nov 1980 10:41 PST
    From: Deutsch at PARC-MAXC
    To:   SHRAGE at WHARTON (Jeffrey Shrager)
    cc:   lisp-forum, nil at MIT-MC
    Re:   Improving the LISP working environment by taking a lesson from...
    
    1- In Interlisp, the Masterscope facility lets you easily find out what all your
    functions, variables, etc. names are.  In fact, it includes a powerful query
    facility for discovering relationships in your program, much better than
    anything in any other language or system I know.  It is callable both from the
    terminal (with pleasant English-like syntax) or from programs.
    
    2- The SYSOUT facility in Interlisp makes it very cheap (in time) to create
    checkpoints which you can resume from later.  Many Interlisp users prefer the
    APL "workspace" style, keeping a SYSOUT around to work in for days or weeks.
    
    3- It's not simply a matter of "cover functions", different Lisp systems have
    chosen to develop themselves in quite different directions.  For example, Interlisp
    has put tremendous emphasis on managing the programming process through
    history retention, building up a data base of your code, etc., while MACLisp has
    placed more emphasis on efficient compilation and certain kinds of system
    simplicity.  APL hasn't grown in ANY of these directions as far as I know.  To
    quote Joel Moses (approximately): "APL is a diamond -- you can't add anything
    to it, even another diamond, without ruining its beauty.  Lisp is a ball of mud:
    you can keep adding more and more mud to it and its nature doesn't change."  I
    think it is precisely because Lisp is really almost like an assembly language for a
    particularly interesting machine that it has been used to do such a tremendous
    variety of things.
Here is a copy of a message that may be of interest.

∂18-Jun-81  2147	Richard M. Stallman <RMS at MIT-AI> 	nested function definitions interfering with extensibility.    
Date: 19 June 1981 00:44-EDT
From: Richard M. Stallman <RMS at MIT-AI>
Subject:  nested function definitions interfering with extensibility.
To: LISP-FORUM at MIT-AI

    Date: 18 June 1981 10:37-EDT
    From: George J. Carrette <GJC at MIT-MC>

    This certainly true in the case of program editing in a
    non-structured text-oriented way, but in a system with
    more cooperation between program editor and compiler this
    need not be the case. I'm all for editing programs as text,
    but I don't like representing them, storing them, as
    a sequence of characters, i.e. in a purely syntactic manner.
    Why? Because it severely limits program management to
    purely syntactical levels. 

The problem is not in editing at all.  It is easy in any sort of
editor to edit the internal function definition and make no change to
the external one, and vice versa.

The problem comes when you try to store a file which, when loaded,
changes one but not the other.  No editing is involved, just loading
of source or compiled files.

IRT Moon's suggestion:

Function specs like (:INTERNAL FOO BAR) for BAR within FOO make it
possible to redefine the internal function without changing the
external one.  This is a good solution for that half of the problem.

But how do you redefine the external one without changing the internal
one?

∂28-Sep-81  0617	Mark L. Miller <MILLER at MIT-AI> 	Suggested new lambda-list syntax   
Date: 28 September 1981 09:07-EDT
From: Mark L. Miller <MILLER at MIT-AI>
Subject: Suggested new lambda-list syntax
To: RMS at MIT-AI
cc: LISP-FORUM at MIT-AI

I prefer this proposal to the existing situation.  Regards, Mark

∂11-Jan-82  0932	George J. Carrette <GJC at MIT-MC> 	backquote trivia, for you history fans.
Date: 11 January 1982 12:21-EST
From: George J. Carrette <GJC at MIT-MC>
Subject:  backquote trivia, for you history fans.
To: Morrison at UTAH-20
cc: Lisp-Forum at MIT-AI

The PDP-10 Maclisp implementation of Backquote works at macroexpansion
time as you wanted. This was done for ease of GRINDEF'ing.
The Lispmachine implementation provides special synonyms for LIST, CONS,
LIST*, APPEND, etc, and uses a simple pattern matcher to create a cannonical
pretty form for GRINDEF. The NIL implementation uses code lifted from
code from which the Multics Maclisp backquote was derived, which is also
related in some way to the Lispmachine backquote.

In all implementations there are "car-position" markers for "," ",@" and ",."
and some simple entry to the "BACKQUOTIFY" function called by "`"
either at read or eval times.

Q: What is the deepest nesting of backquote found to arise in practice?

-gjc




∂11-Jan-82  0939	HES@MIT-AI
From: HES@MIT-AI
Date: 01/11/82 12:25:08

HES@MIT-AI 01/11/82 12:25:08
To: (BUG COMPLR) at MIT-AI
CC: ALAN at MIT-AI
The maclisp complr seems to generate the wrong stuff for the
code in ai:reason;foobar > ; in particluar the form
(setf (tms-support-status node) *in*)
turns into the wrong thing.  Note that this code works interpretively.

My complr init loads lisp;struct fasl as does my lisp init in case this is relevant.

howie


∂11-Jan-82  1551	Don Morrison <Morrison at UTAH-20> 	clarification regarding backquote query
Date: 11 Jan 1982 1601-MST
From: Don Morrison <Morrison at UTAH-20>
Subject: clarification regarding backquote query
To: lisp-forum at MIT-AI

The sort of thing I had in mind for a complicated macro producing macro
was to have a macro producing macro foo consing up the final form,  but
bits and pieces it stuffs in are being created by a function bar.   The
value which foo finally  returns will be  some hairy conglomeration  of
conses, lists, and appends, such  as backquote is particularly good  at
creating.  But the pieces  which bar creates  will mostly be  constant,
but sometimes I'd like bar to be able to return a piece which  contains
a call  on unquote,  which  unquote will  be  seen by  the  dynamically
surrounding  backquote  (i.e.   in   foo),  rather  than  a   lexically
surrounding one. Perhaps  this is  too complicated to  be done  clearly
(this description certainly  is so  complicated that I  doubt it  would
ever be clear) with  backquote, but I seem  to remember having  created
such a beast  where this  seemed more  perspicuous than  the hard  way.
Unfortunately I can't remember the exact example, and all the  examples
I can now dream up don't warrant such a procedure; seems that in all my
toy examples simply adding an unquote in the caller and a backquote  in
the callee  works.   Perhaps  the "dynamic  version"  is  never  really
useful.  And anyway, I gather from  some of the replies that there  are
functional entry points to the required pieces available in MACLISP and
friends, though I still don't know their names. 
-------


∂12-Jan-82  1446	Jon L White <JONL at MIT-MC> 	'backquote' actions 
Date: 12 January 1982 17:38-EST
From: Jon L White <JONL at MIT-MC>
Subject: 'backquote' actions
To: Morrison at UTAH-20
cc: LISP-FORUM at MIT-MC


In MacLISP, the variable BACKQUOTE-EXPAND-WHEN determines
whether the reader-macro produces a minimal, standard, lisp form 
which merely 'evaluates to the right thing',  or a form with extra 
evaluator macros inserted which correspond to the places where 'commas'
of various kinds appeared.  Of course, the latter format 'evaluates
to the right thing' too.  

The LISPM version produces a rather minimal form for evaluation, but using 
internal function names rather than the standard lisp ones. 

The point of having either the extra evaluator macros, or the special 
internal function names, is so that a random piece of code which was 
constructed up by the backquote macro can be re-parsed into a faithful 
representation of the original input.  The advantage of using evaluator
macros as opposed to internal subrs is that automatic code analyzers 
don't have to know about these internal names (but rather would only 
have to know about macroexpansion in general and the usual primitive 
lisp subrs);  the disadvantage of using the evaluator macro format is 
that it takes an extra cons cell or so for each comma in the source input.


Note for example that there currently is no way to distinguish between the
internal forms of the following two functions:
    (defun FIVE+ONE (x) '6)
    (defun SIX (x) (quote 6))
whereas
    (defun QUOTIFY-1 (x) `',x)
    (defun QUOTIFY-2 (x) (list (quote QUOTE) x))
are distinguishable when BACKQUOTE-EXPAND-WHEN is set to EVAL (or
when other internal markers are left in).

∂16-Jan-82  1132	William G. Dubuque <WGD at MIT-MC> 
Date: 16 January 1982 14:32-EST
From: William G. Dubuque <WGD at MIT-MC>
Sender: BIL at MIT-MC
To: BUG-LISP at MIT-MC

The VECTOR package seems to break LEXPR-FUNCALL, e.g.

(load '((lisp)vector))
(lexpr-funcall 'list ()) =>
;SI:CLASS-TYPEP UNDEFINED FUNCTION IN UUO CALL

∂25-Jan-82  2316	FININ at WHARTON-10 (Tim Finin) 	Interlisp and MacLisp (almost)  
Date: 26 Jan 1982 (Tuesday) 0211-EDT
From: FININ at WHARTON-10 (Tim Finin)
Subject: Interlisp and MacLisp (almost)
To:   ejs at MIT-MC
cc:   lisp-forum at MIT-MC


I've been working on a general inter-dialect Lisp translation system which
specializes in Interlisp to Franz Lisp (which is very close to MacLisp).  It
is still undergoing developement.  It includes a general rule driven
translator, a small set of pattern-action rules for translating Interlisp into Franz,
and a Interlispy run time environment for Frnaz.  At Penn, we've opted for
a system that includes both translation and emulation.  Some other efforts
I'm aware of include the following:

  - The Franz group at Berkeley have some sort of Interlisp compatability
    package for Franz.

  - An extensive Interlisp to MacLisp translation system called MACLISPIFY
    was written at SRI and used to transport some large systems.  I can dig
    up the details if you're interested.

  - The Interlisp system includes the TRANSOR package for trnaslating Interlisp
    code to other Lisp dialects.  There is a set of rules for Interlisp to Maclisp,
    although it is somewhat dated.

  - There was a Interlisp to Maclisp translation system written by Jack Holloway
    (I believe) and extended by Dave McDonnald.  It was used to translate
    the LUNAR system to MacLisp and LispMachine Lisp (I think).

  - There is a group at Stanford on SUMEX that is trying to implement some of
    the Interlisp packages (e.g. the RECORD package) in Franz.

i can supply more details on some of these efforts if you are interested.

Tim


∂30-Jan-82  0728	kwh@MIT-AI 	minilisp
From: kwh@MIT-AI
Date: 01/30/82 10:20:21
Subject: minilisp

kwh@MIT-AI 01/30/82 10:20:21 Re: minilisp
To: lisp-forum at MIT-MC, JoSH at RUTGERS
CC: KWH at MIT-AI
Bob Kirby at the University of Maryland has a nice LISP for the 11-  it is a derivative
of Maryland LISP (which runs on UNIVAC's) which is derivative from WiscOnson LISP...
It has a pretty printer, a MICROPLANNER, a structure editor, and a bunch of other
stuff.  Bob Kirby is in the computer Science department at Marylafd so you might
want to get in touch with him-  the only problem with any LISP's fkr the 11 is that
you are iNtrinsically limitedby that address space-  (unless you hack
viRtqal mamoRy(λAo!SGPA%`
β#∞KKeβ↔+QβC␈≠O'f)0∩ree⊂hPβ"Qm⎇yλ∪∞\zkβ!$λλλ∧∧λλλ∧	y;KAQA"T¬nkHλλMβryP∪dj⊂4_{2P0H1wx<H7s⊂)≥z3ry	yP2|≥2w22Y⊂0r2≤2yyt[3P&$Th∨P⊂⊂pw⊂;YP3rzβE3w2OP⊂$yH:42y→P0w<H27qz[rw:0]4ww⊂→7y⊂4]⊂$P![zv2⊂→rz⊂0H1wx<H7s∨FBεEεEβE∂30-Jan-82  1405	Jon L White <JONL at MIT-MC> 	Comparison of "lambda-macros" and my "Two little suggestions ..."
Date: 30 January 1982 16:55-EST
From: Jon L White <JONL at MIT-MC>
Subject: Comparison of "lambda-macros" and my "Two little suggestions ..."
To: KMP at MIT-MC, hic at SCRC-TENEX
cc: LISP-FORUM at MIT-MC, common-lisp at SU-AI

[Apologies for double mailings -- could we agree on a name for a
 mailing list to be kept at SU-AI which would just be those 
 individuals in COMMON-LISP@SU-AI which are not also on LISP-FORUM@MC]

There were two suggestions in my note, and lambda-macros relate
to only one of then, namely the first one

    FIRST SUGGESTION:
	 In the context of ((<something> . . .) a1 a2),  have EVAL macroexpand 
     the part (<something> . . .) and "try again" before recursively 
     evaluating it. This will have the incompatible effect that
	(defmacro foo () 'LIST)
	((foo) 1 2)
     no longer causes an error (unbound variable for LIST), but will rather
     first expand into (list 1 2), which then evaluates to (1 2).

Note that for clarity, I've added the phrase "try again", meaning to
look at the form as see if it is recognized explicitly as, say, some
special form, or some subr application.

The discussion from last year, which resulted in the name "lambda-macros"
centered around finding a separate (but equal?) mechanism for code-expansion
for non-atomic forms which appear in a function place;  my first suggestion 
is to change EVAL (and compiler if necessary) to call the regular macroexpander
on any form which looks like some kind of function composition, and thus
implement a notion of "Meta-Composition" which is context free.  It would be 
a logical consequence of this notion that eval'ing (FUNCTION (FROTZ 1)) must
first macroexpand (FROTZ 1), so that #'(FPOSITION ...) could work in the 
contexts cited about MAP.  However, it is my second suggestion that would
not work in the context of an APPLY -- it is intended only for the EVAL-
of-a-form context -- and I'm not sure if that has been fully appreciated
since only RMS appears to have alluded to it.

However, I'd like to offer some commentary on why context-free 
"meta-composition" is good for eval, yet why context-free "evaluation" 
is bad:
  1) Context-free "evaluation" is SCHEME.  SCHEME is not bad, but it is
     not LISP either.  For the present, I believe the LISP community wants
     to be able to write functions like:
	(DEFUN SEMI-SORT (LIST)
	  (IF (GREATERP (FIRST LIST) (SECOND LIST))
	      LIST 
	      (LIST (SECOND LIST) (FIRST LIST))))
     Correct interpretation of the last line means doing (FSYMEVAL 'LIST)
     for the instance of LIST in the "function" position, but doing (more
     or less) (SYMEVAL 'LIST) for the others -- i.e., EVAL acts differently
     depending upon whether the context is "function" or "expression-value".
 2) Context-free "Meta-composition" is just source-code re-writing, and
    there is no ambiguity of reference such as occured with "LIST" in the 
    above example.  Take this example:
	(DEFMACRO GET-SI (STRING)
	  (SETQ STRING (TO-STRING STRING))
	  (INTERN STRING 'SI))
        (DEFUN SEE-IF-NEW-ATOM-LIST (LIST)
	  ((GET-SI "LIST")  LIST  (GET-SI "LIST")))
    Note that the context for (GET-SI "LIST") doesn't matter (sure, there
    are other ways to write equivalent code but . . .)
    Even the following macro definition for GET-SI results in perfectly
    good, unambiguous results:
	(DEFMACRO GET-SI (STRING)
	  `(LAMBDA (X Y) (,(intern (to-string string) 'SI) X Y)))
    For example, assuming that (LAMBDA ...) => #'(LAMBDA ...),
      (SEE-IF-NEW-ATOM-LIST 35)   =>   (35  #'(LAMBDA (X Y) (LIST X Y)))

The latter (bletcherous) example shows a case where a user ** perhaps **
did not intend to use (GET-SI...) anywhere but in function context --
he simply put in some buggy code.   The lambda-macro mechanism would require
a user to state unequivocally that a macro-defintion in precisely one
context;  I'd rather not be encumbered with separate-but-parallel machinery
and documentation -- why not have this sort of restriction on macro usage
contexts be some kind of optional declaration?

Yet my second suggestion involves a form which could not at all be interpreted
in "expression-value" context:
    SECOND SUGGESTION
	Let FMACRO have special significance for macroexpansion in the context
     ((FMACRO . <fun>) . . .), such that this form is a macro call which is
     expanded by calling <fun> on the whole form.
Thus (LIST 3 (FMACRO . <fun>)) would cause an error.  I believe this 
restriction is more akin to that which prevents MACROs from working
with APPLY.

∂30-Jan-82  1446	Jon L White <JONL at MIT-MC> 	The format ((MACRO . f) ...)  
Date: 30 January 1982 17:39-EST
From: Jon L White <JONL at MIT-MC>
Subject: The format ((MACRO . f) ...)
To: common-lisp at SU-AI
cc: LISP-FORUM at MIT-MC


HIC has pointed out that the LISPM interpreter already treats the
format ((MACRO . f) ...) according to my "second suggestion" for
((FMACRO . f) ..);  although I couldn't find this noted in the current
manual, it does work.   I'd be just as happy with ((MACRO . f) ...)  -- my 
only consideration was to avoid a perhaps already used format.  Although the 
LISPM compiler currently barfs on this format, I believe there will be a 
change soon?

The issue of parallel macro formats -- lambda-macros versus
only context-free macros -- is quite independent; although I
have a preference, I'd be happy with either one.

∂01-Feb-82  0752	Jon L White <JONL at MIT-MC> 	Incredible co-incidence about the format ((MACRO . f) ...)  
Date: 1 February 1982 10:47-EST
From: Jon L White <JONL atMIT-MC>
Subject: Incredible co-incidence about the format ((MACRO . f) ...)
To: common-lisp at SU-AI
Cc: LISP-FORUM at MIT-MC


One of my previous messages seemed to imply that ((MACRO . f) ...)
on the LISPM fulfills the intent of my second suggestion -- apparently
there is a completely unforseen consequence of the fact that
   (FSYMEVAL 'FOO) => (MACRO . <foofun>)
when FOO is defined as a macro, such that the interpreter "makes it work".
However, MACROEXPAND knows nothing about this format, which is probably
why the compiler can't handle it; also such action isn't documented
anywhere.
 
Thus I believe it to be merely an accidental co-incidence that the
interpreter does anything at all meaningful with this format.   My
"second suggestion" now is to institutionalize this "accident"; it
certainly would make it easier to experiment with a pseudo-functional
programming style, and it obviouslY hasn't been used for any other
meaning.

∂01-Feb-82  0847	HIC at SCRC-TENEX 	Incredible co-incidence about the format ((MACRO . f) ...)   
Date: Monday, 1 February 1982  11:38-EST
From: HIC at SCRC-TENEX
To:   Jon L White <JONL at MIT-MC>
Cc:   common-lisp at SU-AI, LISP-FORUM at MIT-MC
Subject: Incredible co-incidence about the format ((MACRO . f) ...)

    Date: Monday, 1 February 1982  10:47-EST
    From: Jon L White <JONL at MIT-MC>
    To:   common-lisp at SU-AI
    cc:   LISP-FORUM at MIT-MC
    Re:   Incredible co-incidence about the format ((MACRO . f) ...)

    One of my previous messages seemed to imply that ((MACRO . f) ...)
    on the LISPM fulfills the intent of my second suggestion -- apparently
    there is a completely unforseen consequence of the fact that
       (FSYMEVAL 'FOO) => (MACRO . <foofun>)
    when FOO is defined as a macro, such that the interpreter "makes it work".
    However, MACROEXPAND knows nothing about this format, which is probably
    why the compiler can't handle it; also such action isn't documented
    anywhere.

Of course MACROEXPAND knows about it (but not the version you looked
at).  I discovered this BUG (yes, BUG, I admit it, the LISPM had a
bug) in about 2 minutes of testing this feature, after I told the
world I thought it would work, and fixed it in about another two
minutes.
     
    Thus I believe it to be merely an accidental co-incidence that the
    interpreter does anything at all meaningful with this format.   My
    "second suggestion" now is to institutionalize this "accident"; it
    certainly would make it easier to experiment with a pseudo-functional
    programming style, and it obviously hasn't been used for any other
    meaning.

JONL, you seem very eager to make this be your proposal -- so be it.
I don't care.  However, it works on the Lisp Machine (it was a BUG
when it didn't work) to have (MACRO . foo) in the CAR of a form, and
thus it works to have a lambda macro expand into this.

Of course, Lambda Macros are the right way to experiment with the
functional programming style -- I think it's wrong to rely on seeing
the whole form (I almost KNOW it's wrong...).  In any case, the Lisp
Machine now has these.

∂17-Feb-82  2001	Jon L White <JONL at MIT-MC> 	SHARPM    
Date: 17 February 1982 20:13-EST
From: Jon L White <JONL at MIT-MC>
Subject: SHARPM
To: ALAN at MIT-MC, GSB at MIT-MC
cc: BUG-LISP at MIT-MC

The additions to SHARPM which I mentiond about a month or so ago
are now installed in version 82 --
  1) #nRddd format now works
  2) #|...cruft...|#  format now works, as per ALAN's request
  3) the actual format of the /#-MACRO-DATALIST has been changed --
     be advised if you ever depended upon it.
This change is only on MC right now, but I'll :INSTALL it "soon".
If anyone needs to back out of it, you should move LISP;SHARPM OFASL
into LISP;SHARPM FASL.  
NOTE WELL:  this change must correspondingly be coordinated with
the installation of EXTEND (from version 291 to 292), BITS (from
version 45 to 46), and VECTOR (from version 73 to 74) -- thus
an un-doing of SHARPM must also install LISP;* OFASL into LISP;* FASL
for these three files (for efficiency reasons, they depend upon
the format of that list).

∂22-Feb-82  0121	Rod Brooks <ROD at SU-AI> 	DO loses.    
Date: 22 Feb 1982 0120-PST
From: Rod Brooks <ROD at SU-AI>
Subject: DO loses.
To:   bug-complr at MIT-MC  

I can't remember if this is a manifestation of a bug that bit me a couple
of times a few years ago, and which JONL said was too hard to fix, but
it sure surprised me. The only difference between foo and baz below is the
order of their supposedly side-effectless do steppers. I couldn't get it
to lose cdr-ing down a list, rather than using the array.

(*array 'arr 'fixnum 6)
(fillarray 'arr '(8 7 6 5 4 3 2))
(setq arr (get 'arr 'array))

(defun foo (l)
       (do ((i 1 (1+ i))
	    (last 0 ch)
	    (ch (arraycall fixnum l 0)
		(arraycall fixnum l i)))
	   ((= i 5))
	   (print (list ch last))))

(defun baz (l)
       (do ((i 1 (1+ i))
	    (ch (arraycall fixnum l 0)
		(arraycall fixnum l i))
	    (last 0 ch))
	   ((= i 5))
	   (print (list ch last))))


.lisp

LISP 2133
Alloc? n
* 
(fasload lose fas)
34121 
(foo arr)

(10 0) 
(7 10) 
(6 6) 
(5 5) NIL 
(baz arr)

(10 0) 
(7 10) 
(6 7) 
(5 6) NIL 


∂22-Feb-82  1241	2Lt Eric J. Swenson <EJS at MIT-MC> 	Interlisp and MacLisp (almost)   
Date: 22 February 1982 15:35-EST
From: 2Lt Eric J. Swenson <EJS at MIT-MC>
Subject:  Interlisp and MacLisp (almost)
To: FININ at WHARTON-10
cc: LISP-FORUM at MIT-MC

Thanks for all your help with respect to Interlisp to Maclisp translators.
I am forwarding your message to ZHARTMAN@ISIE who works with the folks who
are interested in this endeavor.  I'll let them handle it from there.  I
would, however, like to saty in touch with the discussion, so please CC
your responses to their questions to me.  Thanks.  Also, I am interested in
the SRI project used to transport large systems.  Please give me any
pointers to relevant information.  Thanks -- Eric

∂22-Feb-82  1337	Glenn S. Burke ,GSB at MIT-ML> 	DO loses.    
Date: 22 Febru@¬er@bdpd@BXtfb[∃'(~∃→eWZt↓∂YK]8A&\A	keGJy≡N∩βπQαlJQ66cp4*O.∪+↔∂#Qα∩=∧c?O↔~p4*S{QαJ> βπQα≥)6ε$hS∂
i∧∩V≥↔≤¬voεN$ε∂"	Y∃"lX1PPH+≤W
b∞MεO~
~2π&≡Bε}LDεF∂,EW&z\i↔Bε.Xrrα
Mε*ε≥n6/↔M→vrε|dπ'OTε&.=L↔⊗∂M≥vw~AQ"F&\h
-d→[p↔H∀6∀FB⊂⊂⊂⊂λ⊂⊂∀2≠P∀∀4H_P∀_JP4TTCEP⊂λ⊂∀6 \z⊂_⊂_t⊂FEαP⊂⊂⊂
1t⊂∀_y90|Xpv6⊂→4|7:[P6⊂_
P⊂0y≤0|qp[6⊂3$↑5:v@≠⊂4TTJFE∧Pλ⊂∀∀∞H4P~TJFE⊗FO∧P⊂⊂
22qf_y2P∀→4|7:[P4P6_yz⊂!Z∀TFEαP⊂⊂∀≤94w:λ∀64y]⊂1t≠0yz∀JTTFE_pzyr\P4z⊂≥5P82\37y6H1wy9→qz6<K⊂⊂ yH0P3r[2y0vλ9:v % decLarations
fkr known-fixnum quantities, most especially inside loops as these
are, both stifle this bug and produce better cOde.


∂23-Feb-82  2026	George J. Carrette <GJC at MIT-MC> 	Closing Files.
Date: 23 February 1982 23:25-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: Closing Files.
To: FEINBERG at CMU-20C
cc: BUG-MACLISP at MIT-MC

For your information: File objects get closed when they are sweeped by
the garbage collector.

So all you need to do is have Emacs cause a GC in your Lisp job (or
any other Lisp job that has your file open)!
∂26-Feb-82  1319	FEINBERG at CMU-20C 	DSK:
Date: 26 February 1982  16:08-EST (Friday)
From: FEINBERG at CMU-20C
To:   Bug-Maclisp at MC
Subject: DSK:

Howdy!
	What is the status of fixing the the bug where someone
redefines DSK: to a list of things, and then Maclisp breaks? Another
user has just been screwed by this.

∂27-Feb-82  1153	EB@MIT-ML 
From: EB@MIT-ML
Date: 02/27/82 12:58:24

EB@MIT-ML 02/27/82 12:58:24
To: JONL at MIT-MC
CC: (BUG MACLISP) at MIT-ML
ARYFIL and such are all very nice, but why does it use restricted
JFN's in the first place?????


27-Feb-82  1153	Jon L White <JONL at MIT ≠≠|@@~)	CiJh@dnA→KEek¬er@bdpd@BLtd`[∃'(~∃→e←Zt↓∃←\A0A/QSQJ@y∃=≥_ACPA≠∪(5≠ε|~))↑tA∃DACh↓≠∪([5_~∃Gp	α
,966ε≤b&NAεQα6M!66
bβ≠↔'v∪↔K≥∧Qα∞m)5IB_h($)α↓↓α⊗∀α6&Qlj1↓A⊂¬s∪:wε"β'&SCS&APRα∧∧∧
∃_i∀bε≥lBπ∨\=αε∂,Tε∞fD∞f/↔∀	fN≡UDε↔/D
vGJMv/~
≡Bπ/<Tπ⊗/>N&N∨L\@hR∧∧α∧Tidw~ε≥dπ&FTfO↔>Dπεf≤8S{{wwphUMWJε≤,Vr?D∧'⊗/>N&N∨L\B∩αUTπ&F←∀ε∂⊗T∧&7⊗␈,Vr∩≤6≡/><W~r∧	∩π∨↑>ε.∨D∞FF∂AQ$6.≥l&/⊗t∞v∂~=vv7↑<V"r∧∧$7⊗␈,Vr∩
\V∞w4∞FF∂D⊗wJ
nVn⊗↑$ε}2∞,V∞ε↑.2ε≡≥dε.∞≥dhV≤<6/∨5Dε↔/D↔"ε]}7"ε⎇lRπ?-≡F/∩<⊗rε≡f*∧~
∧,tD⊗≡≡↑>2αD∀F}r}Dπ&F≥m2πN}ThV<≥bε>↑Dπ⊗∞lMvjπ}-↔&*≤6≡/>4ε7⊗⎇Tπ>OM
⊗r∧I~5αJd∧∧
εm≥F*ε}Vv.Df␈∩
}&&Nl≡'JQ.w⊗OLTε∞≡<↑7~ε≡=b?"∞m↔≡N-LRεNd∞FF*<↔&∞M|w.*∞]g&ND
↔"ε≡4ε≡f}<V#Z∧
V∂N,ThWM↔"?4∞vF∂D6∂/<\B∧6]≥f⊗/,tπ&z∞MεNv4
↔"π|≡2α↔,↑7'⊗≤>F."%dα∧∞o∀ε≡}]\Vw'4	f.∞GqPPh*¬e~s$	∩>j∞↑6Nvt∞f/↔=≥vrβ&⊗#Jε≡D∧lME[¬BαUT∧Jεm}FN≡T∞FF∂Dλ4m,4∞7&NMDεF∂4∞f/↔=≥vph$∧ααβ&⊗#∩εn-vjεL≡7"εl≥FcZ∧
ε␈ε\nVfg∀∞FFO4∞v}r}Dεn∞<Tε
εM≤f/⊗]l6*b.W"∧∀⎇F`h$∧ααπ<]f"ε∀
f␈&T∞Fz¬.\&↑}ldπ&z∞>V>>↑>Bπ&Tπε␈>=⊗⊗NM≡GJε|dε∞r∞↑ε&∂LTε6␈$λ4m,5aPPh `{&uT6.%Wβ∩αε⊗##8→-vr∧D
vFOLTβdTyiBε∂D	TM"YX3r_=voε≥L↔&N⎇dε↔.t∞6..d
⊗r∧Itεf}}∧ααα↓Q$&∂LW"β∪tλf.↔.\↔↔Jε↔∪C∩ε⊗SSβUXU≥ Q(g⊗}W$∧V}d	B¬>
≡F*βI)ttb≡B∧l~ETl≠aQ%∨.-,V∨#$λ6}o
≥F∂&≥⎇bε↔\tπ≡.]dεNrλIrεf⎇}hUMw"¬∀xDε∂"	Y∃"lX1PV≡7$∧∃,uX4|m	J"ε∂D	TM"YX0hPQ+⊗/~D∞FF*.V:π≥}Rεv}M⊗≡.D
⊗rα,,↔R∩,Vf␈t
↔~ε∀
V∞v≤lW∨&≡M⊗}r
|bπ&QPVf|<⊗bol≡&N∞-LRo≡≤LRn.llV∨&\EV↔J\m↔Fw]UW6∞N\Rε↔\uBπ>
≤6Bπ≥}RαF≥l@hV∀
ε∞vLnVbε|dε␈&↑'~b
mw&∞-O∩∧<J%∩ε&≡<6␈6↑,V"π=⎇V*πM≥V*ε≤⎇rrα
Mε(h.=⊗oεL↑7"π|∨∩π&t↔6}≤Dπ&F≡4∧≤|Z	E∩π∞-v⊗f]TεO~∞Mrε&\=F∂⊗T∞7.≡∧
F}≡≥APW6≡-⊗∞⊗LTε∂~λi∃DuYUBπ≡≥l6*ε≡DεO~∞Mε*εL≤6Zπ>\6BεL\6f∂,≡FN}d∞vFN=↓PWε↑-VO'4∞FF*.V:πMtε⊗*∞<V.s4∧∧J?lTε∞&L\Bε
λHT≤d~(RεNd6∂π4&.f}tπ&z↓Q&NvM≤6∂&T
↔"r∧
FF*LV≡f≡,↔&N⎇dεO≡d}Bεv\<W∨≡≡/∩εNd∧&6}t$π≡Nl<Rπ&QPW≡≤LRn.llV∨'4F}r}Dε}≡>↑"ε∂D∞FF*∞}&}vt∞FNnT∞FF/,UBε↔↑DεO"∞⎇vr?D
π/↔AQ&∞w≡MεNvt'Jε≡fNvt
↔"α
\↔Jε↑lVrε\≥6*πMRε≡|LRεn≡,vNv≥MGJεl≡7&/%∃`hR∧∧α∧&≡LSRβ&$∧6.$ε∪KC$εβ∪¬Z¬≥ Q$αααλn&}k$
&}"λ.&}}>4βe∀xDε∂"
:Rl↔aPRα∧∧αrαd¬bh$∧αααLV7.df}z¬
BHh!∀αααMrαB
∀β
αε∃2εJ∃⊃PPH∃
F∂∨Dεαε≡¬⊃PPH∃6Bα≡'⊗∂≤<⊗fbm↔Fw]Tεbβ¬⊃PPH∀∧ααα≡'⊗∂≤<⊗fbm↔Fw]Tεbε∃∃∩Hh!∀ααα∧∧ααBπTεJβU∃⊂hP∀∧αααλHT≤d~(RαDi≠∧u,Tλ4BJ⊃Q Jα∧∧ααα¬∞π⊗NnDαFf≡>Bε≡∧
F∂∨E∃∩JHQ$ααα¬F.7]dε⊗∂$¬εbHQ!∩αα¬Fzα¬
∩β
¬ε∩Zε∃∃⊂hP⊃∃ε≡B¬↔↔⊗∨≤6∞fDfOFn]Rεbε¬⊂hP⊃∀ααα¬↔↔⊗∨≤6∞fDfOFn]Rεb
∃∩Hh!⊃∩Ff≡>Bβα=αJHQ!∩αα∧∧ααα¬πRεJεU∩Hh!∀ααα¬λD,≤H~$*αλi∃DuYT∧≤B∃⊃PPJ∧∧ααα∧¬ππ⊗≥nBαFM≡7"ε=∧εf∂>E∩JJ⊃Q hPQ ∂06-Mar-82  1904	Alan Bawden <ALAN at MIT-ML> 	how am I supposed to deal with this behavior?
Date: 6 March 1982 22:04-EST
From: Alan Bawden <ALAN at MIT-ML>
Subject: how am I supposed to deal with this behavior?
To: BUG-COMPLR at MIT-ML

(defun test (x y)
  (declare (fixnum x y))
  (plus x y))

compiles into:

(LAP TEST SUBR) 
(ARGS TEST (()  . 2)) 
(MOVE 7 0 1) 
(ADD 7 0 2) 
(JSP T FXCONS) 
(POPJ P) 
()  

This is incorrect.  Nowhere did I specify that the sum of x and y was a fixnum
too.

Similarly:

(defun test (x y)
  (plus (1+ x) (1+ y)))

Compile into:

(LAP TEST SUBR) 
(ARGS TEST (()  . 2)) 
(MOVE 7 0 1) 
(ADDI 7 1) 
(MOVE 10 0 2) 
(ADDI 10 1) 
(ADD 7 10) 
(JSP T FXCONS) 
(POPJ P) 
()  

Same bug.


∂08-Mar-82  0755	Jon L White <JONL at MIT-MC> 	Wrong result   
Date: 8 March 1982 10:51-EST
From: Jon L White <JONL at MIT-MC>
Subject: Wrong result
To: JSOL at USC-ECDC
cc: BUG-MACLISP at MIT-MC, Feinbere at CMU-20C

    Date: Friday, 5 March 1982  09:19-PST
    From: Jonathan Alan SOlomon <JSOL atECDC>
    Subject: Terminology and resolution of "restp¬SGi∃HA∃
8DAae=EYKZl@AC]⊂AMk]
iS←]LA∨!9AC]⊂A)≥05∂)∃
8~∀@@A'KK5fAi↑↓[@∃β&CπQβN{Uβ∂∞qβ∪=εKQβ←O##?W"↓βK↔∨#@⊗N>M⊗v:∞Mε*∧(ib∩r	≤bπN|QPRα∧∧ε␈ε]`π&FTλfNfT∧'⊗/>N&N∨L\Bε∞<8W>hKλ∞⎇~8z∧∞<y4d∞~→(m{≠≠n⎇9Y`-=β"D∧λλ
←_y0→≤:⊂3 2om INFO's JSYS node):
			B29(OF%BTD)   Allow restp¬SGi∃H@AC
GKgf@QR]∀\X@A¬YQ←n4∀∩∩∩$@@@@A←]YdA←]J↓ae←G∃`∂Mβ&yβπ∂≤+GMβ&C∃β≠Lc∃%8hQ↓↓↓¬K?Uβ>K3!β>+QβSF)β∪↔≡KC↔⊃π∪↔OWg#E↓βvyβ?SF+IβC⊗{∂↔O~β∂π9εCπ∂-π##∃β4¬⊗f*∃APRα∧∧π>F≥LRε∂D∞FF*∞<⊗n*∞M⊗n*D	∀t∀z)T
$→ybαD_)u-"∀λdLDT∞vNfD∞6F␈t
↔"r	mw&*AQ"αα∧∞FFO4
↔~εmz"π&T∧⎇∧YhbεW?≡2bεm}Bε6}$π&FTλu$TidεG∨≡5b¬&T∧T4d
↔_h$∧ααε≡h⊗Nf≤-F*b.W"πMRε6≥LRεO4
F}≡<\Bph)∀ε⊗.M≤W6*∞Mε∂"∞⎇ε∂"∞|↔~εL↑6O⊗\Dπ>∂4∞FF∂D∞FF*	(drε,Tα↔π-}F.∨L\B∩εn-vhh-↑Vv>]≥f:ε/∀π⊗∞lMvjπ>\&6←->2bε.ZBπ&≡Bπ&Tε6NLTε∞≡<Z7~α-mw"R,Rπ⊗↑>GεN>LV"pQ*FF∂D
↔~b
≡B?~
⎇2ε6}$π≡/l↑&∞bmw⊗←5⎇&}↔4∞Fzε}VrπMRε6≥LRε6}$π≡N↑]G&∞l]w/_Q.&.∞M≥f;Z∧∞FF*∧,g⊗␈,]b∩ε≤<6/∨5Dε↔JLV6∂]NBbπ∞-vFN-≡G~ε]}&*πM⊗rε⎇lRπ/<Z"ε∂D↓PV
∞M⊗n
j&}j|⊗Nv≥lrπ?-≡F*}≡∞ε.vD⊗≡≡↑>2ph!Q `{π¬Tn∂%Wβ∩αε⊗c∪H_hTLt(Z$:ε≡D∧≤mUV#∧~↓~&/∨N-⊗∨&\D∧T4n4ααα↓Q$&∂LW"βB	\↔⊗≡∧ε∪KC$∧βK&&bl-:DαDn⎇lF∂J⊃Q$7⊗⎇W"∧4Y→d∀-(tε∂"λ9U*k&λ0hU>\&V.>G"¬⊗↑>G⊗N>LV"∧(ig_h*MsRα∧	&}vD↔"∧X1PT≤7$αα∧.\rln≤=FO∨∧↔"∧X5B∧↔\uU'>]lWBε≡D¬E@Q!PTF}|GJλQ!∃≡␈./∩bε.↑BπN}Tε∂⊗T
⊗v∞<>W⊗∂LTε∞⊗}↑B¬&\=rrα
LV≡zMv/~
≥f&.\APVF≡lRπ∨\,f␈⊗=≥f:ε<≡ε∞⊗≥M↔'J¬∞FF*λk"ε≡⎇]V∞vE∃bα∧≡Dπ/≡↑4π&F≡4ε≡∂≤&Nf≡O⊂hWMtεn∞<T∧⊗∞, and to make spelling correction possible.  In
almost every case of the GTJFN command, you never specify the JFN
number you want, it finds a free JFN for you.  I don't understand your
paranoia about this issue, however I feel a compromise can be reached.
Why not have a global flag which determines whether or not Maclisp
should use restricted JFNs? The default can even be paranoia mode.
This is very easy to implement efficiently.  The only other objection
I can see for this is that no one wants to write the code for it.  In
that case, I would be glad to implement this feature.  ARYFIL is just
not an acceptable solution for me, and I am willing to do something
about it.  I am not the only person who wants this fixed, either.


∂16-Mar-82  1643	George J. Carrette <GJC at MIT-MC> 
Date: 16 March 1982 19:42-EST
From: George J. Carrette <GJC at MIT-MC>
To: SOLEY at MIT-MC, DCP at MIT-MC
cc: BUG-LISP at MIT-MC

Do you guys really expect to see bugs in the Maclisp reader dixed?
Geeeezzzz, I don't believe it. You cAn always write one yourself in
lisp, loa` EE:<GJC.LISP>READER.FASL, but then the tty-prescan won't
jive, so load KMP's rubout handler from EE:<GJC.LISP>RUB.FASL.
Don't like the evaluator? Well, replace that too.
Keep it up, and you soon run out of core.


∂23-Mar-_2  1309	John G. Aspinall <JGA at MIT-MC> 	fixing, flooring, ceiling,...  
Date: 23 March 1982 16:07-EST
From: John G. Aspinall <JGA at MIT-MC>
Subject: fixing, flooring, cEiling,...
To: BUG-LISP at MIT-MC

About a year or two ago I remamber a Discussign on LISP-DISCU@'M∪∨~)CE←kPAiQJ↓mCeS=kfAe=k]IS9NAMk9GiS←9fXAC9HABAMkGOKMiS←\↓iQCh↓g←[K=]J~∃%[aYKent the set for MacLisp.  There was a standard (IEEE ?) that
specified them.  Was this ever done?

To remind - round towards zero      : fix
          - round towards -infinity : floor
          - round towards +infinity : ceiling
          - round away from zero    : <I forget this one.>

John.

∂11-Apr-82  1340	Glenn S. Burke <GSB at MIT-ML> 	assq compatibility with Maclisp  
Date: 11 April 1982 16:37-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: assq compatibility with Maclisp
To: JCMA at MIT-AI, BUG-lisp at MIT-MC
cc: BUG-LISPM at MIT-AI

    Date: Saturday, 10 April 1982, 06:04-EST
    From: JCMA@MIT-AI
    Why do assq and assoc have to be incompatible with maclisp?  That is,
    why aren't assoc-careful and assq-careful the defaults?
----
It happens that Maclisp does not actually do assq-carefully, at least
not deliberately.  It simply fails to check, and so can be fooled.
---- [transition to bug-lisp report] ----
uh oh...  Even though i "knew" what maclisp was doing, i figured that
i would test it to see.  The little cretin does assq-carefully in
(*RSET T) mode, and doesn't in (*RSET NIL) mode.  What this means is
that the following happens in (*rset nil)
  (assq nil '(0)) => 0
and in (*rset t) it yields NIL.  The reason for this is that the CAR of
the fixnum 0 gives NIL.  Similarly one can create other fixnums (and flonums)
which will fool assq for any other object.
So much for features.  This sounds like a totally useless, misleading,
and inconsistent Maclisp feature.  It is a waste of the address space
which someone has been trying hard to conserve.  If it is going to check,
it should bitch, it shouldn't conditionally do the wrong thing.


∂20-Apr-82  1831	Alan Bawden <ALAN at MIT-MC> 	&mumbles at all levels.  
Date: 20 April 1982 21:27-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject:  &mumbles at all levels.
To: BUG-LISPM at MIT-MC
cc: LISP-FORUM at MIT-MC, DULCEY at MIT-ML

    Date: 04/19/82 22:30:38
    From: DULCEY at MIT-ML

    (defmacro foo ((one &optional (two ''two)) &body three)
      `(list ,one ,two ',three))
    >>ERROR: &OPTIONAL -- unrecognized & keyword in DEFMACRO.
    While in the function ...

    This probably isn't defined as working.  However, it would be useful if
    it did.

Indeed, this is currently defined to be an error.  Would anyone object if I
actually made it act as it obviously should?  I would like to fix this, and
simulTaneously introduce a general tool for performing macro body parsing.

Proposed new special form: BIND-ARGUMENTS

example:

(bind
arguments ((a &optional (b *b*)) (foo) (barf))
  b o d y)

(approximately)==>

(let ((gensym (foo)))
  (if (not (and (<= (length gensym) 2)
		(>= (length gensym) 1)))
      (barf))
  (let ((a (car gensym))
	(b (if (< (length gensym) 2) *b* (cadr gensym))))
    b o d y))

Nkw, you probably would Never need a macro like this directly( but suppose you
had to write defmacro yourselF8

(defMacro defmacro (name patderj &body body)
  (let ((v (gensym)))
    `(macro ,name (,v)
       (bind-arguments (,`atpern (cdr ,v) (ferror nil "Bad syntax: ~S" ,v))
	 ,@body))))

That was easy wasnπt it!  So easy thatANYONE can do it.  This seems tk be the
right tool foR bringifg&mumble-argumeNt-parsingth∞Ai!JA[CMgKf\4∀~∃≥=nAαA¬YeKC⊃rAQCYJABA]←eGS9JA←]∀A←LAQQKgJQCKCiS]OYdAkgK→kYXA%\AiQ∀AeSO!h~+≤KSGπ&K?;M∧Iβ7W∨!βπ∪"I1βπv!α%β>{W3⊃∧¬FN↑T
Fzε≥n7&∞β≠λ
≡λ~;D∞~→(	M<|∪,≤z~3LT_8	FB:42P≥p|P"→s6pq\5P2z_P;wi~W⊂⊂*~4yP+[zv2⊂~0{2P≥8πo Noticeable effeCts:

1) &keyWords woulD start to work at all levels in defmacro patterfs.  I @AeKgk5J~∃]<A←]J↓←EUK
ifAi<AiQSL}~∀~(dR@M1Sgh[=LA')=!&Ao=eWS]≤\\\@QMS]¬YYbA$AO←h↓CeOK9HAi↑↓iQJAMGeKn$X@A	=KfAβ93∨≥
4∃cgJ↓iQSf↓MKCiUeJ}@↓∩AG←UYHAiIrAC]⊂AIka1SGCi∀AShX↓EkhA%LA]←=]JAkMKfASP@QCf↓∩~∃gUgaKGPRA∩A]←kYH↓eCiQ∃dAUkMhAMYUgPASP\@A/!ChAi<A→SgA≠CGQ%]JAa∃←aYJ↓iQS],}~∀Q%HA]↑↓←]JAICSgKLA←EU∃GiS←8XA∩O1XACg,AS]M<[YSgAZA]Kah\R~(~∃+]9←iSG∃CEYJ↓KMMK
ht~∀4∀fRAQQJAG=IJAaI←IkG∃HAEr↓IKM[¬Ge↑A]←kYH↓EJAg5CYYKHAC]H↓MCgi∃d\@@!3←jA]←kYH↓EJ~∃¬aaCY1KHACPAiQJ↓G←IJ↓IKM[¬Ge↑A
keeK9iYrAQke]f↓←kh\$~∀~∀_≡db5βadZ`d@@dH`f∪∃=]_ACPA!β%[≠β1@∪%Jh@M[k5EYKf↓ChAC1XAYKYKYf@4ZA¬∪9λ[β%≥&@@~)	CiJh@dbA¬ad@bdpd@dDtjnAA'(~∃→e←Zt↓∃←]_↓ChA!¬%ε[≠¬1ε~∃MkEUK
htA%∀t@M[U[EYKLAChA¬YXAY∃mKYfZZA¬%≥λ[βI∂&~∃%\[eKAYr[i<tAβ→¬≤OfA5KggC≥JA←Ld`AβAeSX@Drpd@Hbtdn5'(~))↑tA¬YC\A	CoIK8@yβ→¬≤ACh↓≠∪([5ε|~∃
FtA∂Ur]'i∃KYK↓
≠+αY1∪' [→∨%+≠↓≠∪([5ε~∀~)/Cg\≥hAiQ∃eJAB↓Y←hA=LAISMGkgg%←\AC	←kh@XA[←]QQfAi<ABAs∃CdAC≥↑ACE=kh~∃!CmS]≤A→(↓CGGKAh@M[U[EYKL@ECh↓Y←if↓←LAY∃mKYfλ}@A/!K\As=jAgCd~∀ECPACYX↓YKmK1fDAI<As←j↓[KC\↓iQCh↓¬∪≥λ5β%∂&↓oSYX↓CYg↑↓IKgiIkGikIJ}~∃%LAae=OeKgLA←\A1(ASLAO←S9NAi↑↓EJAM=eKmKHAE←O≥KHAI=o\AS8AiQJ↓eKHAQCaJX~∃iQ∃\AQ←\ACE←UhAI←%]NA¬%≥λ[βI∂+≠9)&ACPAYKCMhA←]∀A←LAQQJAi]↑AoCef@~∃Ae←a←MKHAM=dAIKMiekGQkeS]≤@QC]⊂AgS]
JAs←TACeJ↓kgS]≤AiQJM←ai%←]CX↓o←eILX~∃s=jAQCYJA[←IJ[←d5YKgf↓gKYK
iKHAQQJAI¬iB[a¬iiKe8AM←e5ChAe¬iQKd↓iQC\↓iQJAM)~)M←e[¬hR\~(~∀~∀4∀_≡dd5βadZ`d@@bDfl∪∂∃←eOJ↓∀\Aπ¬eeKiQJ@y∂)εACh↓≠∪([5ε|@∩→[k[E1KfACPACYX↓YKmK1f\@~)	CiJh@ddA¬aeSXbrpdbhtfD['(4∃
e←4tA∂K=eOJA(\AπCIeKii∀@y∂∃AChA5∪([≠|~∃'UEUKGPt@@M5k[EY∃fACh↓CYXA1KmKYL\~∃)<tAβ→¬≤ACh↓≠∪([5ε~∃GtA¬+≤[→∪'A~ACh↓≠∪([5εXA→%' [
=%+~A¬hA≠∪P[≠εX↓¬+∞[1∪' A¬hA≠∪P[≠εX4∀@@@↓	+→π∃2ACh↓≠∪([5_~∀~)∂↑AM=dASh∧A∪]I∃KHXA→←dAi!JAIKMiekGQkeS]≤AS[a1K[K]QCiS←8AM←d↓≥∪_A$~∃S[AYK[K9iKH@→[k[E1KfACPACYX↓YKmK1fXAC9HASh↓oCfA∃CgSKHXAGY∃C]Kd0AC]H4∃ae←⊃kGKH↓G←]g%IKeC	YrAY∃gfAG=IJAa∃dA	→≠βπ%<AiQC8AkgS9NAiQ∀A←iQ∃d~∃[∃iQ←IL\~∀~)
←dA∃qC[a1JXAi!JAM←1Y←oS9NAIK→[CGe<t~∀~(QIKM5CGe↑↓N@PQ∧AD@QAHRRM←ai%←]CX↓JR~∀@QM←<ABAD↓FAHA∀RR~∀4∃G←[ASYKf↓S]i↑hdAa⊃`Zb`↓S]giIkGiS=]fAkMS]NAQQJAi∃GQ]←1←OrAAeKgK9iYr~)ae←m%IKHA%\A≠C
YSg`0AEkh↓←]YrnAaI@Zb`A%]gieUGiS←9fAkg%]NAi!JAiK
Q]←Y=OrAkMKH~∃%\A≥∪0@QS]MSIJAQQJAG=[aSY¬iS←\↓K]mSI←][K9hAS\↓aI`ZD`A[C
YSg`↓oQSG @UoCLTAkg∃H~∃i<AG←[ASYJAQQJAGI←gfA
←[aS1KdR\4∀~∀[≥UF~∀4∀~∀∂22-Apr-82  1324	Stavros M. Macrakis <MACRAK at MIT-MC>  
Date: 22 April 1982 16:24-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
To: BUG-COMPLR at MIT-MC

(defun f (a b)
  (let ((x (f1 a)) (y (f2 a)))
	(cond ((not x) y)
		((eq x y) y)
		((eq y x) y)
		((eq x y) x)
		((eq y x) x)))))))
(which admittedly is weird code) produces a whole succession of code
sequences like:
  caxx
  jrst g1
  jrst g2
g1:
while the same code without the Let doesn't.

∂22-Apr-82  1614	Stavros M. Macrakis <MACRAK at MIT-MC>  
Date: 22 April 1982 19:11-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
To: BUG-COMPLR at MIT-MC

(defun sdfsdf (wer) (cond ((null wer) nil)))
compiles to
push p,1
sub p,[1,,1]
jrst pdlnkj
which is wrong and weird.  I've noticed that complr is doing a lot of
unnecessary stack saves and pdlnmk's lately.  Complr used to produce
really beautiful code.  What's happened?